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REMARKS 

Tanenbaum Text: The Examiner is thanked for expediting the faxing to counsel of a more 
complete copy of the Tanenbaum reference, that is, one in which the edges of the text are 
more fully copied, and more of the pages referencing the cited Figures are included. 

Summary: Appreciation is expressed for the allowance of claims 22-30, and for the 
objections to claims 4, 5, 9-12, 18, 19, 33 and 34, which are indicated as defining patentable 
subject matter. Claims 4, 9, 18, and 33 have been amended to become independent claims, 
including all limitations of the parent and any intervening claims, avoiding the basis for 
objecting to claims 4, 5, 9-12, 18, 19, 33 and 34. Arguments are made for the patentability of 
rejected claims 1,2,6,7, 15, 20, 21, and 31, and of claims 3, 8, 13, 14, 17, and 32. Claim 16 
has been amended to define certain configurations of the failover driver, and arguments are 
made for the patentability of this claim. Allowance of all pending claims is respectfully 
requested. 

Specification Amendments: Pages 11, 12, 14, and 15 have been amended to correct minor 
typographical errors without adding new matter. Page 1 1 corrects "multi-path", page 12 
inserts "as", page 14 deletes "to" and page 15 inserts "to". Acceptance of these minor 
corrections is respectfully requested. 

Response To Rejections Based on Marks et al Patent 5,790,775 ("Marks") and The 
Tanenbaum Text ("Tanenbaum") 

Rejections: Claims 1, 2, 6, 7, 15, 16, 20, 21, and 31 were rejected based on 35 USC 
Section 103 based on Marks and Tanenbaum, and Claims 3, 8, 13, 14, 17, and 32 were 
rejected based on 35 USC Section 103 based on Marks and Tanenbaum as applied to claim 1, 
in view of Hall Pub 2001/0016904A1 ("Hall"). Thus, all rejected claims were based on a 
combination of Marks and Tanenbaum. Reconsideration of these rejections is respectfully 
requested, for the following reasons. 

The Combination of Marks and Tanenbaum Does Not Meet The 35 USC 103 Test: 
It is submitted that the combination of Marks and Tanenbaum is not proper because 
there is no proper teaching, motivation, or suggestion for the combination. Initially, it is 
submitted that the Court of Appeals for the Federal Circuit (CAFC) has consistently held in 
determining whether a proposed combination of references is proper under the standard of 35 
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USC 103, that actual evidence of the suggestion, teaching or motivation to combine is 
required. For example, in In re Dembiczak , (CAFC case 98-1498, 4/28/99), the Court made it 
clear that the showing must be clear and particular, and that Examiner's statements 
unaccompanied by evidence or reasoning are inadequate to support the rejection. Further, the 
Court made it clear that particular factual findings regarding the suggestion, teaching, or 
motivation to combine are required, since they identify factual disputes, for example. Implicit 
in this requirement for factual findings, is that the facts found must be correct . 

The Motivation For Combination Cited In The Rejections: The claim rejections 
asserted that Marks teaches both a user interface and an object module. It was acknowledged 
that Marks does not "explicitly teach segregated user interface" and not "a driver being 
configured by the object module" (page 3). It was further asserted that Marks does teach an 
interface that allows the user to configure the controllers and set controllers in a fai lover 
mode. It was asserted that Tanenbaum teaches a segregated user interface, and a driver as 
configured on page 288, and that Tanenbaum is a reference book teaching well-known 
systems of common use. 

The rejections stated that it would have been obvious under 35 USC 103 to combine 
the Marks teachings of a failover system that is user configured, with the Tanenbaum 
teachings of a segregated used interface in which a driver is configured to result in a failover 
system with a segregated user interface. 

The reasoning in support of the rejection was that motivation to combine is present 
although Marks does not explicitly teach the segregated user interface and the driver 
configuration, because Marks was said to teach a failover system in which the user is able to 
change the configuration of controllers through a user interface. 

The reasoning in support of the rejection was further that Tanenbaum teaches that it 
was common knowledge that drivers are necessary to communicate with and access a 
system's hardware, i.e., the controllers of Marks. It was said that Tanenbaum also teaches 
that the drivers in such a system were contained in the kernel space, as opposed to user space, 
resulting in a segregated interface. The asserted common knowledge was to include the 
segregated interface and driver teachings of Tanenbaum with the Marks failover system. 

It is seen therefore, that the premise of the rejections is that: 

(1) drivers are necessary to communicate with and access the controllers of the Marks 
failover system, and 

(2) drivers in such a system were contained in the kernel space, as opposed to user 
space, resulting in a segregated interface. 
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Further, it is clear that Tanenbaum is relied on for a direct and exclusive teaching of the 
drivers being contained in the kernel space, as opposed to user space, resulting in the 
segregated interface. 

The Facts Do Not Support The Asserted Motivation Cited In The Rejections: For the 
following reasons, it is respectfully submitted that the facts do not provide the motivation to 
combine. 

First, Tanenbaum is properly considered "as a whole" under these rejections. In this 
regard, Section 5.3.1 contains the cited Fig. 5-10. This section of Tanenbaum is entitled 
"Interrupt Handlers". At page 287, it is stated that "interrupts are an unpleasant fact of life 
and cannot be avoided. They should be hidden away. . .so that as little of the operating system 
as possible knows about them..". A "model" for handling interrupts is set forth on page 288, 
and it is said that the "model works best if drivers are structured as kernel processes. . .". 
However, page 288 continues, and states "Of course, reality is not so simple." Processing of 
interrupts is described as a complex undertaking, involving some 10 exemplary tasks. In the 
middle of page 289, concern is expressed over the number of machine cycles required for 
processing related to interrupts. 

Second, under the heading "5.3.2 Device Drivers", at page 289 Tanenbaum defines 
device drivers, and states that ". . .the device driver normally has to be part of the operating 
system kernel, at least with current architectures". However, facts not acknowledged in the 
rejection include Tanenbaum going on to state that (see top of page 290) 

"Actually, it would be possible to construct drivers that ran in user space, with calls 
for reading and writing the device registers. In fact, this design would be a good idea, 
since it would isolate the kernel from the drivers and the drivers from each other . 
Doing this would eliminate a major source of system crashes — buggy drivers that 
interfere with the kernel in one way or another." (emphasis added) 
Third, the only apparent reason for not placing the drivers in user space, as stated by 
Tanenbaum, is that "current operating systems expect drivers to run in the kernel" (page 290). 

It is respectfully submitted that these facts do not support the asserted motivation to 
combine and achieve segregated user interface, such that the combination is not proper. 

By definition, the goal of a failover system is to minimize problems resulting from 
failed systems. The clear teaching of Tanenbaum, over-looked in the rejections, is that there 
are major disadvantages arising out of placing the driver in the kernel space . Those 
disadvantages should be considered in an "as a whole" review of Tanenbaum. Moreover, 
when those disadvantages are properly considered, the direct Tanenbaum teaching is: 
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(1) drivers in the user space are a good idea , and 

(2) an idea that would eliminate a major source of system crashes. 

Further, contrary to expectations of current operating systems that "expect drivers to run in 
the kernel" (page 290), the more specific teaching of Tanenbaum of avoidance of drivers in 
kernel space is consistent with the objects of a failover system in reducing risks of failure. 
Clearly, in view of Tanenbaum saying that putting the drivers in the kernel is a major source 
of system crashes, when one skilled in the art is configuring a system to minimize the effects 
of failure, one skilled in the art would not be motivated to configure the system to provide a 
major source of system crashes. 

As advanced above, the Court in In re Dembiczak made it clear that not only is it 
required to have particular factual findings regarding the motivation to combine, but the 
implicit requirement for factual findings is that the facts found must be correct . It is 
respectfully submitted that it is not correct to rely on the Tanenbaum teaching of "current 
operating systems expect drivers to run in the kernel", for example, for motivation to create a 
segregated user interface system, because that reliance would incorrectly be done only by 
ignoring the more pertinent facts found in the same reference. Those more pertinent facts 
would configure the system so as to avoid a segregated user interface and avoid a major 
source of system crashes . Therefore, although Tanenbaum teaches that drivers in a system of 
Fig. 5-10 were contained in the kernel space, as opposed to user space, resulting in a 
segregated interface, Tanenbaum makes it quite clear that the "asserted common knowledge" 
of segregated user interfaces would not properly apply to the Marks failover system, because 
Tanenbaum's avoidance of drivers in kernel space, achieved by the opposite teaching of 
drivers in user space, is consistent with the objects of a failover system in reducing risks from 
failure. 

In view of these remarks, it is respectfully requested that the combination of Marks 
and Tanenbaum be withdrawn as a basis for rejection of claims 1, 2, 6, 7, 15, 16, 20, 21, and 
31 (based on Marks and Tanenbaum) and of claims 3, 8, 13, 14, 17, and 32 (based on Marks 
and Tanenbaum as applied to claim 1, in view of Hall). When the combination is withdrawn, 
in view of the acknowledgements as to claimed features not shown by Marks, it is believed 
that allowance of these claims is in order, which action is respectfully requested. 

Allowed Claims: Appreciation is expressed for the allowance of claims 22-30. Minor 
amendments have been made to claims 25 and 28 to correct inadvertent typographical errors, 
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the correction of which does not add new matter nor change the scope of the claims. 
Continued allowance of these claims 25 and 28 is respectfully requested. 

Objected To Claims: Appreciation is expressed for the remarks as to claims 4, 5, 9-12, 18, 
19, 33 and 34, which are indicated as defining patentable subject matter. Claims 4, 9, 18, and 
33 have been amended to become independent claims, including all limitations of the parent 
and any intervening claims, avoiding the basis for objecting to claims 4, 5, 9-12, 18, 19, 33 
and 34. A minor amendment is made to claim 18 to correct "multi-path", an inadvertent 
typographical error, the correction of which does not add new matter nor change the scope of 
the claim. Allowance of these claims 4, 5, 9-12, 18, 19, 33 and 34 is respectfully requested. 

Amended Claim 16: Consideration of amended claim 16 as being patentable is respectfully 
requested. This claim now sets forth characteristics of the previously defined failover driver. 
This failover driver is described on pages 16-17, for example, in a manner that supports the 
present text. The failover driver is configured to direct I/O requests to storage devices using 
the defined multi-paths, and devices in such paths, for example. The failover driver is 
configured to detect the multi-paths and to determine prior and current status of the multi- 
paths. Additionally, the failover driver is further configured to calculate a failure probability 
for each detected path based on the respective prior and current status of the multi-path and to 
select, for the communication with the storage device, the path having a lowest probability of 
failure. 

It is respectfully submitted that the cited failover reference to Marks does not teach or 
suggest the features of amended claim 16. In detail, when the Marks controllers are placed in 
"dual-active, redundant configuration" C9, L16+, the user makes a command. That command 
instructs one controller to "take over" for the other controller (C9, L28) when there is 
controller failure (L29). The surviving controller assumes control of the target IDs of the 
failed controller (C10, L19), and services those targets (L20). 

It is respectfully submitted that the failover operations of Marks does not teach or 
suggest the claimed path detection, or determination of prior and current status of the multi- 
paths, or failover driver configured to calculate a failure probability for each detected path 
based on the respective prior and current status of the multi-path, nor the selection, for the 
communication with the storage device, of the path having a lowest probability of failure. 
Rather, the C9 and 10 disclosures, for example, simply describe the above-noted "take over" 
by one controller of the operations of another controller, and not any intelligent path selection 
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operations. More specifically, there is no calculation, for example, of a failure probability for 
each detected path. 

Tanenbaum and Hall, cited for other concepts than failover, also do not do not teach 
or suggest the claimed features of claim 16. Thus, no combination of configurations is set 
forth for path detection, or determination of prior and current status of the multi-paths, or 
failover driver configured to calculate a failure probability for each detected path based on the 
respective prior and current status of the multi-path, nor the selection, for the communication 
with the storage device, of the path having a lowest probability of failure. 

Consideration of amended claim 16 as being patentable is respectfully requested. 

In view of these remarks, a Notice of Allowance is therefore respectfully requested. 

If the Examiner has any questions concerning the present amendment, the Examiner is 
kindly requested to contact the undersigned at (408) 749-6900, x6908. 



710 Lakeway Drive, Suite 170 
Sunnyvale, CA 94085 
Telephone: (408) 749-6900, x6908 
Facsimile: (408) 749-6901 
Customer No: 25920 



Respectfully submitted, 
MARTINE & PENILLA, LLP 




Chester E. Martine, 
Reg. No. 19,711 
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